home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1378 < prev    next >
Text File  |  1995-07-25  |  28KB  |  899 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          B. Parker
  8. Request for Comments: 1378                                Cayman Systems
  9.                                                            November 1992
  10.  
  11.  
  12.                The PPP AppleTalk Control Protocol (ATCP)
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  25.    encapsulating Network Layer protocol information over point-to-point
  26.    links.  PPP also defines an extensible Link Control Protocol, and
  27.    proposes a family of Network Control Protocols (NCPs) for
  28.    establishing and configuring different network-layer protocols.
  29.  
  30.    This document defines the NCP for establishing and configuring the
  31.    AppleTalk Protocol [3] over PPP.
  32.  
  33.    This memo is a joint effort of the AppleTalk-IP Working Group and the
  34.    Point-to-Point Protocol Working Group of the Internet Engineering
  35.    Task Force (IETF).  Comments on this memo should be submitted to the
  36.    ietf-ppp@ucdavis.edu mailing list.
  37.  
  38. Table of Contents
  39.  
  40.    1.     Introduction ..........................................    2
  41.    2.     A PPP Network Control Protocol (NCP) for AppleTalk ....    2
  42.    2.1    Sending AppleTalk Datagrams ...........................    3
  43.    2.2    Half-Routers ..........................................    4
  44.    3.     ATCP Configuration Options ............................    4
  45.    3.1    AppleTalk-Address .....................................    5
  46.    3.2    Routing-Protocol ......................................    7
  47.    3.3    Suppress-Broadcasts ...................................    8
  48.    3.4    AT-Compression-Protocol ...............................    9
  49.    3.5    Server-information ....................................   10
  50.    3.6    Zone-Information ......................................   12
  51.    3.7    Default-Router-Address ................................   13
  52.    APPENDICES ...................................................   14
  53.    A.     ATCP Recommended Options ..............................   14
  54.    REFERENCES ...................................................   15
  55.  
  56.  
  57.  
  58. Parker                                                          [Page 1]
  59.  
  60. RFC 1378                        PPP ATCP                   November 1992
  61.  
  62.  
  63.    ACKNOWLEDGEMENTS .............................................   15
  64.    SECURITY CONSIDERATIONS ......................................   16
  65.    CHAIR'S ADDRESS ..............................................   16
  66.    AUTHOR'S ADDRESS .............................................   16
  67.  
  68. 1.  Introduction
  69.  
  70.    PPP has three main components:
  71.  
  72.       1. A method for encapsulating datagrams over serial links.
  73.  
  74.       2. A Link Control Protocol (LCP) for establishing, configuring,
  75.          and testing the data-link connection.
  76.  
  77.       3. A family of Network Control Protocols (NCPs) for establishing
  78.          and configuring different network-layer protocols.
  79.  
  80.    In order to establish communications over a point-to-point link, each
  81.    end of the PPP link must first send LCP packets to configure and test
  82.    the data link.  After the link has been established and optional
  83.    facilities have been negotiated as needed by the LCP, PPP must send
  84.    NCP packets to choose and configure one or more network-layer
  85.    protocols.  Once each of the chosen network-layer protocols has been
  86.    configured, datagrams from each network-layer protocol can be sent
  87.    over the link.
  88.  
  89.    The link will remain configured for communications until explicit LCP
  90.    or NCP packets close the link down, or until some external event
  91.    occurs (an inactivity timer expires or network administrator
  92.    intervention).
  93.  
  94. 2.  A PPP Network Control Protocol (NCP) for AppleTalk
  95.  
  96.    The AppleTalk Control Protocol (ATCP) is responsible for configuring,
  97.    enabling, and disabling the AppleTalk protocol modules on both ends
  98.    of the point-to-point link.  ATCP uses the same packet exchange
  99.    machanism as the Link Control Protocol (LCP).  ATCP packets may not
  100.    be exchanged until PPP has reached the Network-Layer Protocol phase.
  101.    ATCP packets received before this phase is reached should be silently
  102.    discarded.
  103.  
  104.    The AppleTalk Control Protocol is exactly the same as the Link
  105.    Control Protocol [1] with the following exceptions:
  106.  
  107.    Frame Modifications
  108.  
  109.       The packet may utilize any modifications to the basic frame format
  110.       which have been negotiated during the Link Establishment phase.
  111.  
  112.  
  113.  
  114. Parker                                                          [Page 2]
  115.  
  116. RFC 1378                        PPP ATCP                   November 1992
  117.  
  118.  
  119.    Data Link Layer Protocol Field
  120.  
  121.       Exactly one ATCP packet is encapsulated in the Information field
  122.       of a PPP Data Link Layer frame where the Protocol field indicates
  123.       type hex 8029 (AppleTalk Control Protocol).
  124.  
  125.    Code field
  126.  
  127.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  128.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
  129.       and Code-Reject) are used.  Other Codes should be treated as
  130.       unrecognized and should result in Code-Rejects.
  131.  
  132.    Timeouts
  133.  
  134.       ATCP packets may not be exchanged until PPP has reached the
  135.       Network-Layer Protocol phase.  An implementation should be
  136.       prepared to wait for Authentication and Link Quality Determination
  137.       to finish before timing out waiting for a Configure-Ack or other
  138.       response.  It is suggested that an implementation give up only
  139.       after user intervention or a configurable amount of time.
  140.  
  141.    Configuration Option Types
  142.  
  143.       ATCP has a distinct set of Configuration Options, which are
  144.       defined below.
  145.  
  146. 2.1.  Sending AppleTalk Datagrams
  147.  
  148.    Before any AppleTalk packets may be communicated, PPP must reach the
  149.    Network-Layer Protocol phase, and the AppleTalk Control Protocol must
  150.    reach the Opened state.
  151.  
  152.    Unless otherwise negotiated (via option 4), exactly one AppleTalk
  153.    packet is encapsulated in the Information field of a PPP Data Link
  154.    Layer frame where the Protocol field indicates type hex 0029
  155.    (AppleTalk).
  156.  
  157.    Note that the negotiation of compression may imply the use of
  158.    different encapsulation and hence different protocol fields.  These
  159.    different protocol fields imply packet types which are sub-protocols
  160.    of the base AppleTalk NCP.
  161.  
  162.    An encapsulated AppleTalk packet begins with an extended DDP
  163.    (Datagram Delivery Protocol) header -- also known as a Long DDP
  164.    header.  The maximum length of a DDP datagram is 599 octets.
  165.  
  166.    Since there is no standard method for fragmenting and reassembling
  167.  
  168.  
  169.  
  170. Parker                                                          [Page 3]
  171.  
  172. RFC 1378                        PPP ATCP                   November 1992
  173.  
  174.  
  175.    AppleTalk datagrams, it is required that PPP links supporting
  176.    AppleTalk allow at least 599 octets in the information field of a
  177.    data link layer frame.
  178.  
  179. 2.2.  Half-Routers
  180.  
  181.    One model for routers in [3] is two remote AppleTalk routers linked
  182.    as "half-routers" without a Node ID or Network number assigned to
  183.    either side of the link.  When acting as half-routers, the only
  184.    effect on transported packets is that the hop count is incremented
  185.    when it is received over the link.  Routing updates received over a
  186.    half-router link should also increment the hop count of routing table
  187.    updates.
  188.  
  189.    As part of normal operation, AppleTalk will send RTMP Routing updates
  190.    every 10 seconds.
  191.  
  192. 3.  ATCP Configuration Options
  193.  
  194.    ATCP Configuration Options allow negotiation of desirable AppleTalk
  195.    parameters.  ATCP uses the same Configuration Option format defined
  196.    for LCP [1], with a separate set of Options.
  197.  
  198.    The most up-to-date values of the ATCP Option Type field are
  199.    specified in the most recent "Assigned Numbers" RFC [2].  Current
  200.    values are assigned as follows:
  201.  
  202.    1       AppleTalk-Address
  203.  
  204.    2       Routing-Protocol
  205.  
  206.    3       Suppress-Broadcasts
  207.  
  208.    4       AT-Compression-Protocol
  209.  
  210.    5       RESERVED
  211.  
  212.    6       Server-information
  213.  
  214.    7       Zone-information
  215.  
  216.    8       Default-Router-Address
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Parker                                                          [Page 4]
  227.  
  228. RFC 1378                        PPP ATCP                   November 1992
  229.  
  230.  
  231. 3.1.  AppleTalk-Address
  232.  
  233.    Description
  234.  
  235.       This Configuration Option provides a way to negotiate the
  236.       AppleTalk network and node number to be used on the local end of
  237.       the link.  It allows the sender of the Configure-Request to state
  238.       which AppleTalk-address is desired, or to request that the peer
  239.       provide the information.  The peer can provide this information by
  240.       NAKing the option, and returning a valid AppleTalk-address.
  241.  
  242.       If negotiation about the remote AppleTalk-address is required, and
  243.       the peer did not provide the option in its Configure-Request, the
  244.       option SHOULD be appended to a Configure-Nak.  The value of the
  245.       AppleTalk-address given must be acceptable as the remote
  246.       AppleTalk-address, or indicate a request that the peer provide the
  247.       information.
  248.  
  249.       By default, no AppleTalk address is assigned.  A network or node
  250.       number specified as zero in a Configure-Request shall be
  251.       interpreted as requesting the remote end to specify a value via a
  252.       Configure-Nak.  A network or node number specified as zero in a
  253.       Configure-Ack shall be interpreted as agreement that no value
  254.       exists.
  255.  
  256.       An implementation which requires that no AppleTalk addresses be
  257.       assigned (such as a intermediate system to intermediate system
  258.       "half-routing") MUST Configure-Reject all AppleTalk-Address
  259.       Configuration Options.
  260.  
  261.       An implementation which requires that AppleTalk addresses be
  262.       assigned to it (such as a end system) MUST fail configuration if
  263.       the remote side Configure-Rejects all AppleTalk-Address requests,
  264.       or fails to provide a valid value.
  265.  
  266.       If this option is negotiated, the two sides MUST negotiate a
  267.       common AppleTalk network number and two unique Appletalk node
  268.       numbers.  The network number MAY be zero but the Appletalk node
  269.       numbers MUST be non-zero.  Values selected for network and node
  270.       numbers must adhere to the ranges defined in [3].
  271.  
  272.       The AppleTalk protocol, phase 2, defines the concept of "extended"
  273.       and "non-extended" networks.  Extended networks can support a
  274.       large number (hundreds) of nodes, and requires multiple network
  275.       numbers and multiple zone names to be managed effectively.  Non-
  276.       extended networks can only support a small number of devices, and
  277.       require only a single network number and zone name to be managed
  278.       effectively.
  279.  
  280.  
  281.  
  282. Parker                                                          [Page 5]
  283.  
  284. RFC 1378                        PPP ATCP                   November 1992
  285.  
  286.  
  287.       If a PPP link transporting AppleTalk is assigned an AppleTalk
  288.       address, it must have the "non-extended" characteristics as
  289.       defined in [3].
  290.  
  291.       The format of the network and node data is defined to be the same
  292.       as the "AppleTalk address" in [3], chapter 3, "AppleTalk AARP
  293.       packet formats on Ethernet and token ring".
  294.  
  295.    A summary of the AppleTalk-Address Configuration Option format is
  296.    shown below.  The fields are transmitted from left to right.
  297.  
  298.     0                   1                   2                   3
  299.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  300.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  301.    |     Type      |    Length     |    Reserved   |     AT-Net    |
  302.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  303.    |     AT-Net    |    AT-Node    |
  304.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  305.  
  306.  
  307.    Type
  308.  
  309.       1
  310.  
  311.    Length
  312.  
  313.       6
  314.  
  315.    Reserved
  316.  
  317.       This octet is reserved and MUST be set to zero on transmission and
  318.       ignored on reception.
  319.  
  320.    AT-Net
  321.  
  322.       The two octet AT-Net is the desired local AppleTalk network number
  323.       of the sender of the Configure-Request.  This two octet quantity
  324.       represents a 16 bit unsigned number sent "network byte order"
  325.       (most significant octet first).
  326.  
  327.    AT-Node
  328.  
  329.       The one octet AT-Node is the desired local AppleTalk node ID of
  330.       the sender of the Configure-Request.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Parker                                                          [Page 6]
  339.  
  340. RFC 1378                        PPP ATCP                   November 1992
  341.  
  342.  
  343. 3.2.  Routing-Protocol
  344.  
  345.    Description
  346.  
  347.       This Configuration Option provides a way to negotiate the use of a
  348.       specific routing protocol.  In particular, "half-routers" may want
  349.       to exchange routing information using a protocol optimized for the
  350.       PPP connection.  By default, AppleTalk RTMP (Routing Table
  351.       Maintenance Protocol) routing information is sent over the PPP
  352.       connection.
  353.  
  354.       By default, AppleTalk RTMP routing information is sent over the
  355.       PPP connection.
  356.  
  357.    A summary of the Routing-Protocol Configuration Option format is
  358.    shown below.  The fields are transmitted from left to right.
  359.  
  360.     0                   1                   2                   3
  361.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  362.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  363.    |     Type      |    Length     |       Routing-Protocol        |
  364.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  365.    |    Data ...
  366.    +-+-+-+-+
  367.  
  368.  
  369.    Type
  370.  
  371.       2
  372.  
  373.    Length
  374.  
  375.       >= 4
  376.  
  377.    Routing-Protocol
  378.  
  379.       The Routing-Protocol field is two octets and indicates the type of
  380.       Routing-Protocol desired.  This two octet quantity represents a 16
  381.       bit number sent "network byte order" (most significant octet
  382.       first).
  383.  
  384.       Negotiation of some routing protocols implies that you will
  385.       receive packet types which transport these protocols.
  386.  
  387.       For example, negotiating AppleTalk AURP to exchange routing
  388.       information implies both sides will accept EDDP type packets,
  389.       since this is the transport type used by AURP.
  390.  
  391.  
  392.  
  393.  
  394. Parker                                                          [Page 7]
  395.  
  396. RFC 1378                        PPP ATCP                   November 1992
  397.  
  398.  
  399.       Initial values are assigned as follows:
  400.  
  401.       Value       Protocol
  402.  
  403.         0         No routing information exchange
  404.         1         AppleTalk RTMP is used to exchange routing information
  405.         2         AppleTalk AURP is used to exchange routing information
  406.         3         AppleTalk ABGP is used to exchange routing information
  407.  
  408.  
  409.    Data
  410.  
  411.       The Data field is zero or more octets and contains additional data
  412.       as determined by the routing protocol indicated in the Routing-
  413.       Protocol field.
  414.  
  415.       None of the Routing-Protocol options defined here require
  416.       additional data.
  417.  
  418. 3.3.  Suppress-Broadcasts
  419.  
  420.    Description
  421.  
  422.       This Configuration Option provides a way to negotiate the
  423.       suppression of AppleTalk broadcast datagrams which might otherwise
  424.       use up limitted PPP bandwidth.  This Configuration Option is used
  425.       to inform the remote end that no AppleTalk broadcast datagrams of
  426.       a given DDP type should be sent.
  427.  
  428.       This option is useful when negotiated by a single end system.  It
  429.       allows the local end system to request that broadcast packets
  430.       generated on a remote network not be propagated across the PPP
  431.       link.  In the case of a single end system connected to a large
  432.       network, this can be used to suppress regular NBP lookups
  433.       generated by other end systems on the remote network.  This will
  434.       mean that protocols such as NBP can no longer be used to find
  435.       network entities on the local system, but since the option
  436.       configuration is asymmetric, it does not inhibit the local
  437.       system's ability to find network entities on the remote network.
  438.  
  439.       By default, no AppleTalk broadcast datagrams are suppressed.  Note
  440.       that this option may conflict with other options (such as Routing
  441.       Protocol).  If so, the Suppress-Broadcasts option takes
  442.       precedence.
  443.  
  444.    A summary of the Suppress-Broadcasts Configuration Option format is
  445.    shown below.  The fields are transmitted from left to right.
  446.  
  447.  
  448.  
  449.  
  450. Parker                                                          [Page 8]
  451.  
  452. RFC 1378                        PPP ATCP                   November 1992
  453.  
  454.  
  455.     0                   1                   2                   3
  456.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  457.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  458.    |     Type      |    Length     |  DDP-Type  1  |  DDP-Type  2  |
  459.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  460.    | etc...
  461.    +-+-+-+-+
  462.  
  463.  
  464.    Type
  465.  
  466.       3
  467.  
  468.    Length
  469.  
  470.       >= 2
  471.  
  472.    DDP-Types
  473.  
  474.       A vector of one or more single octet DDP type values, each of
  475.       which are to be suppressed if sent to the broadcast address.
  476.  
  477.       If no data is present (the length = 2), all broadcast packets are
  478.       to be suppressed, regardless of DDP type.
  479.  
  480. 3.4.  AT-Compression-Protocol
  481.  
  482.    Description
  483.  
  484.       This Configuration Option provides a way to negotiate the use of a
  485.       specific compression protocol.  By default, compression is not
  486.       enabled.
  487.  
  488.    A summary of the AT-Compression-Protocol Configuration Option format
  489.    is shown below.  The fields are transmitted from left to right.
  490.  
  491.     0                   1                   2                   3
  492.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  493.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  494.    |     Type      |    Length     |   AT-Compression-Protocol     |
  495.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  496.    |    Data ...
  497.    +-+-+-+-+
  498.  
  499.  
  500.    Type
  501.  
  502.       4
  503.  
  504.  
  505.  
  506. Parker                                                          [Page 9]
  507.  
  508. RFC 1378                        PPP ATCP                   November 1992
  509.  
  510.  
  511.    Length
  512.  
  513.       >= 4
  514.  
  515.    AT-Compression-Protocol
  516.  
  517.       The AT-Compression-Protocol field is two octets and indicates the
  518.       compression protocol desired.  Values for this field are always
  519.       the same as the PPP Data Link Layer Protocol field values for that
  520.       same compression protocol.
  521.  
  522.       The most up-to-date values of the AT-Compression-Protocol field
  523.       are specified in the most recent "Assigned Numbers" RFC [2].
  524.       Current values are assigned as follows:
  525.  
  526.  
  527.          Value (in hex)          Protocol
  528.  
  529.                                  none defined
  530.  
  531.  
  532.    Data
  533.  
  534.       The Data field is zero or more octets and contains additional data
  535.       as determined by the particular compression protocol.
  536.  
  537. 3.5.  Server-information
  538.  
  539.    Description
  540.  
  541.       This Configuration Option provides a way to obtain information
  542.       about the communications server providing the remote side of the
  543.       PPP connection.
  544.  
  545.       The nature of this option is advisory only.  It is provided as a
  546.       means of improving an end system's ability to provide a simple
  547.       user interface.
  548.  
  549.    A summary of the Server-Information Option format is shown below.
  550.    The fields are transmitted from left to right.
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Parker                                                         [Page 10]
  563.  
  564. RFC 1378                        PPP ATCP                   November 1992
  565.  
  566.  
  567.     0                   1                   2                   3
  568.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  569.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  570.    |     Type      |    Length     |          Server-class         |
  571.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  572.    |                   Server-implementation-id                    |
  573.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  574.    |  Server-name ...
  575.    +-+-+-+-+-+-+-+-+-+-+-+-+
  576.  
  577.  
  578.    Type
  579.  
  580.       6
  581.  
  582.    Length
  583.  
  584.       >= 8
  585.  
  586.    Server-class
  587.  
  588.       The Server-class field is two octets and indicates the class of
  589.       the communication server providing the remote end of the PPP
  590.       connection.
  591.  
  592.       Initial values are assigned as follows:
  593.  
  594.       Value        Class
  595.  
  596.         1          AppleTalk PPP Dial-in server.
  597.  
  598.                    The server-implementation-id is a four byte version
  599.                    id, with the first byte defined as the major
  600.                    version number (1-255) and the second byte defined
  601.                    as the minor version number (1-255).
  602.  
  603.                    The third and fourth bytes are undefined and should
  604.                    be zero.
  605.  
  606.         2          Generic AppleTalk PPP implementation.
  607.  
  608.                    The server-implementation-id is undefined and
  609.                    vendor specific.
  610.  
  611.         3          Both dial-in server and router
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Parker                                                         [Page 11]
  619.  
  620. RFC 1378                        PPP ATCP                   November 1992
  621.  
  622.  
  623.    Server-implementation-id
  624.  
  625.       The Server-implementation-id field is four octets and indicates
  626.       the version of the communication server providing the remote end
  627.       of the PPP connection.
  628.  
  629.    Server-name
  630.  
  631.       This optional field contains the "AppleTalk ASCII" name of the
  632.       server.  The character codes used in "AppleTalk ASCII" are defined
  633.       in [3], appendix D, "Character codes".  The length of the name is
  634.       bounded by the option length.
  635.  
  636. 3.6.  Zone-Information
  637.  
  638.    Description
  639.  
  640.       This Configuration Option provides a way to obtain information
  641.       about the AppleTalk zone used for the PPP connection.
  642.  
  643.       The nature of this option is advisory only.  It is provided as a
  644.       means of improving the end system's ability to provide a simple
  645.       user interface.
  646.  
  647.    A summary of the Zone-Information Option format is shown below.  The
  648.    fields are transmitted from left to right.
  649.  
  650.     0                   1                   2                   3
  651.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  652.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  653.    |     Type      |    Length     |           Zone-name...        |
  654.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  655.  
  656.  
  657.    Type
  658.  
  659.       7
  660.  
  661.    Length
  662.  
  663.       >= 3
  664.  
  665.    Zone-name
  666.  
  667.       This field contains the "AppleTalk ASCII" zone name in which the
  668.       server resides.  The character codes used in "AppleTalk ASCII" are
  669.       defined in [3], appendix D, "Character codes".  The length of the
  670.       name is bounded by the option length.
  671.  
  672.  
  673.  
  674. Parker                                                         [Page 12]
  675.  
  676. RFC 1378                        PPP ATCP                   November 1992
  677.  
  678.  
  679. 3.7.  Default-Router-Address
  680.  
  681.    Description
  682.  
  683.  
  684.       This Configuration Option provides a way to obtain information
  685.       about a "default" Appletalk router which may be used to obtain
  686.       network information such as zone names.  It is provided as a means
  687.       of obtaining the address of a router in the case both sides of the
  688.       link are end systems.
  689.  
  690.       Any AppleTalk RTMP packets received should supercede information
  691.       negotiated in this option.
  692.  
  693.       By default, no default router is present.
  694.  
  695.    A summary of the Default-Router-Address Option format is shown below.
  696.    The fields are transmitted from left to right.
  697.  
  698.     0                   1                   2                   3
  699.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  700.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  701.    |     Type      |    Length     |    Reserved   |     AT-Net    |
  702.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  703.    |     AT-Net    |    AT-Node    |
  704.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  705.  
  706.  
  707.    Type
  708.  
  709.       8
  710.  
  711.    Length
  712.  
  713.       6
  714.  
  715.    Reserved
  716.  
  717.       This octet is reserved and MUST be set to zero on transmission and
  718.       ignored on reception.
  719.  
  720.    AT-Net
  721.  
  722.       The two octet AT-Net is the AppleTalk network number of the
  723.       default router.  This two octet quantity represents a 16 bit
  724.       unsigned number sent in "network byte order" (most significant
  725.       octet first).
  726.  
  727.  
  728.  
  729.  
  730. Parker                                                         [Page 13]
  731.  
  732. RFC 1378                        PPP ATCP                   November 1992
  733.  
  734.  
  735.    AT-Node
  736.  
  737.       The one octet AT-Node is the AppleTalk node ID of the default
  738.       router.
  739.  
  740. A.  ATCP Recommended Options
  741.  
  742.    The ATCP is designed to support three different modes of operation.
  743.    Each mode places constraints on the configuration options used and
  744.    the values negotiated.
  745.  
  746.    The options for server information, zone information and default
  747.    router address are "informational" options provided by one end of the
  748.    connection and are not intended to be negotiated.  These options are
  749.    provided to support a higher level of service to dial-in end systems.
  750.  
  751.    The options which SHOULD be negotiated in each case are outlined
  752.    below.  Any option not listed may be rejected.
  753.  
  754. End System to Intermediate System - "dial-in"
  755.  
  756.    This mode of operation is intended to support end system dial-in.
  757.  
  758.          1       AppleTalk-Address (required)
  759.          2       Routing-Protocol (required, no routing protocol)
  760.          3       Suppress-Broadcasts (optional)
  761.          4       AT-Compression-Protocol (optional)
  762.          6       Server-information (optional, request from end system)
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Parker                                                         [Page 14]
  787.  
  788. RFC 1378                        PPP ATCP                   November 1992
  789.  
  790.  
  791. Intermediate system to Intermediate system - with network number
  792.  
  793.    This mode of operation is intended to support WAN-to-WAN, i.e.,
  794.    router to router, connections where the link is configured with a
  795.    network number.
  796.  
  797.          1      AppleTalk-Address (required, nets must be zero or equal)
  798.          2      Routing-Protocol (optional)
  799.          3      Suppress-Broadcasts (optional)
  800.  
  801. Intermediate system to Intermediate system - without network number
  802.  
  803.    This mode of operation is intended to support WAN-to-WAN, i.e.,
  804.    router to router, connections where the link is not configured with a
  805.    network number.  Routers in this mode are referred to as "half-
  806.    routers" in [3].
  807.  
  808.          1      AppleTalk-Address (optional, nets & nodes MUST be zero)
  809.          2      Routing-Protocol (optional)
  810.          3      Suppress-Broadcasts (optional, suppress all broadcasts)
  811.  
  812. References
  813.  
  814.    [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
  815.        Daydreamer, May 1992.
  816.  
  817.    [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  818.        USC/Information Sciences Institute, July 1992.
  819.  
  820.    [3] Sidhu G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk,
  821.        Second Edition", Addison-Wesley Publishing Company, Inc., May
  822.        1990.
  823.  
  824. Acknowledgments
  825.  
  826.    Some of the text in this document is taken from previous documents
  827.    produced by the Point-to-Point Protocol Working Group of the Internet
  828.    Engineering Task Force (IETF).
  829.  
  830.    This document is derivative of drafts written by the following
  831.    people.  Many thanks for their work, and for taking an initial stab
  832.    at the protocol:
  833.  
  834.    Steve Senum (sjs@network.com), Network Systems Corporation
  835.    Jim Muchow (muchow@anubis.network.com), Network Systems Corporation
  836.    Frank Slaughter (fgs@Shiva.COM), Shiva Corporation
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Parker                                                         [Page 15]
  843.  
  844. RFC 1378                        PPP ATCP                   November 1992
  845.  
  846.  
  847. Security Considerations
  848.  
  849.    Security issues are not discussed in this memo.
  850.  
  851. Chair's Address
  852.  
  853.    The working groups can be contacted via the current chairs:
  854.  
  855.    Brian Lloyd
  856.    Lloyd & Associates
  857.    3420 Sudbury Road
  858.    Cameron Park, California 95682
  859.  
  860.    Phone: (916) 676-1147
  861.    EMail: brian@lloyd.com
  862.  
  863.  
  864.    John Veizades
  865.    Apple Computer, Inc.
  866.    20525 Mariani Avenue
  867.    Cupertino, CA 95014
  868.  
  869.    Phone: (408) 996-1010
  870.    EMail: veizades@apple.com
  871.  
  872. Author's Address
  873.  
  874.    Questions about this memo can also be directed to:
  875.  
  876.    Brad Parker
  877.    Cayman Systems, Inc.
  878.    26 Landsdowne Street
  879.    Cambridge, Ma 02139
  880.  
  881.    EMail: brad@cayman.com
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Parker                                                         [Page 16]
  899.